Closed Bug 1448918 Opened 6 years ago Closed 6 years ago

Migrate Firefox Desktop's first run experience from a web page to an in-product experience

Categories

(Firefox :: General, enhancement, P3)

Product:
Firefox
Component:
General
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 62
Tracking Flags:
Tracking Status
firefox62 + fixed

People

(Reporter: cmore, Assigned: ewright)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

(Keywords: feature)

Attachments

(2 files, 2 obsolete files)

Link to GitHub pull-request: https://github.com/mozilla/activity-stream/pull/4090
52 bytes, text/x-github-pull-request
Details | Review
Bug 1448918 - Create about:welcome page in preparation for firstrun migration.
59 bytes, text/x-review-board-request
dmosedale
: review+
Details 
A concept that has been discussed over the past year is to move desktop's first run experience from an external www.mozilla.org load to an in-product experience. 

This migration could look something like:

1) Create a new about:welcome in-product page.

2) Migrate the content and FxA button from https://www.mozilla.org/en-US/firefox/59.0/firstrun/ to about:welcome.

3) Perform an A/B test of the startup.homepage_welcome_url pref using about:blank, about:welcome and https://www.mozilla.org/%LOCALE%/firefox/%VERSION%/firstrun/ as variation values with the success criteria as having a no statistically significant regression on core product metrics (including day 1 or week 1 retention).

In-Product Benefits:

a) Given that speed/fast is value props that are connected to our good/mission statements, we want to ensure that that the first experience re-enforces those statements. Moving the first run experience into the product will reduce any network latency and load time of external resources hosted on an external website.

b) Related to speed, having about:welcome would allow Activity Stream content to be pre-fetched/loaded so that about the user interacts with about:welcome or skips it, Activity Stream will immediately load.

c) Given that about:welcome would be a privileged in-product page, additional future functionality of the page won't be constrained to what is possible on a website and with the legacy UITour API.

d) The entire onboarding experience can be QA'd, tested and optimized as a complete standalone experience without having to rely on a separate code base (www).

d) Activity Stream and Shield infrastructure can run experiments to modify the about:welcome experience for an a/b test.

e) Firefox would load without a "Hmm. We’re having trouble finding that site." error if a network connection isn't present at the time of the install.

Possible challenge:

a) A/B testing about:welcome could currently be bit more challenging since in-product testing tools load after Firefox is open and by that point, the about:welcome page could be already loaded. This could be resolved by improving the delay in delivering an experiment recipe or using a funnelcake to test the end-to-end experience. 

User stories:

As a new user of Firefox, I want to quickly perform an action, so I can get Firefox to help me with the reason I installed Firefox today.

As a product manager of Firefox desktop, I want an in-product first run experience, so that the initial experience with Firefox is quick, error free, and provides immediate user value.

There have been mock-ups and example code on how this could function and those folks will attach them shortly.
Hi Peter, as Product Manager on Desktop, I want to get your feedback on this request on this migration.
Flags: needinfo?(pdolanjski)
Blocks: photon-onboarding
Hi Maria. Could get your feedback here from an Activity Stream perspective?
Flags: needinfo?(mpopova)
(In reply to Chris More [:cmore] from comment #1)
> Hi Peter, as Product Manager on Desktop, I want to get your feedback on this
> request on this migration.

I'm fully supportive.  I agree that it's a good idea to run this as an experiment to make sure we don't have unexpected results that skew the numbers.
Flags: needinfo?(pdolanjski)
Alex: can you review this document and provide any feedback or approvals from an FxA perspective?
Flags: needinfo?(adavis)
/document/bug/ :)
I am also in support of the proposed direction and experimentation cadence.
Flags: needinfo?(mpopova)
I think that this is a step in the right direction for moving onboarding into the product and making it a continuous thing rather than a one off (because onboarding should never really end).

I also agree that this can greatly improve the mechanisms we have available for onboarding given /firstrun won't be stuck in a webpage.

And A/B testing the same content hosted on about:welcome vs /firstrun will be great for understanding any impacts related to that.

As per FxA, I think we need to get the /firstrun page to a state where there is no iFrame so that you can also test about:welcome without it. I don't think it would be a good idea to have an iFrame in a locally hosted page.

Questions/Concerns that I have:
- As you mentioned, the speed at which we can iterate about:welcome. I am not convinced yet that we could have good velocity, the key to rapidly learning and iterating.
- How can we keep the marketing team involved despite it being moved to the product? They seem really motivated to help improve onboarding and we should nourish that. Just thinking out loud... Perhaps one/two people from retention marketing could be embedded in these efforts to form an agile team.
Flags: needinfo?(adavis)
:adavis: agree with the statements and all concerns.

For everyone here, here's an approach we could try to get from where we are at today to an in-product experience, given there are some sequential steps that are needed:

1) Marketing is working on layout, copy, image small sample experiments on the /firstrun/ page. They are working with Alex Davis on making sure the tests are measured against retention and multi-device sync using Amplitude. Let's find something that performs and feels better than what we have now while maintaining a consistent voice and experience. We will likely quickly reach a local maxima and general diminishing returns on copy tests on the page given past tests here.

2) Now that the onboarding program is kicked off, let's get Aaron Benson (UX pod lead) embedded in the layout/UX of the tests from step 1. Also, get Michelle Heubusch (content strategy lead) embedded in the review of the copy to ensure the variations (if something wins) is lined up to the overall Firefox strategy. We can still test and try new things at low volumes, but if something were to win, we should ensure it is still lined up to how the product talks to the user. If we find a winner and the winner isn't aligned to the content strategy, we may have to re-test or throw out the variation.

3) Let's get the iframe removed and replaced with an email form+button on the existing /firstrun/ page. This will resolve a number of issues including virus programs breaking the iframe, which is a real issue facing users today.

4) The layout, copy, iframe changes/test will take us into Q2. We can then use that final version of /firstrun/ (from steps above)to use as the first iteration of the about:welcome page. 

5) Figure out how we could technically perform a/b tests on an in-product about:welcome page with a similar velocity than we can now within a web page. Given that in-product vs web page is a different thing all together, it may take a different approach to find velocity. This could potentially be done via Shield, Activity Stream, Funnelcake (custom binary) or Attribution (seeing a cohort like a funnelcake without a custom binary) or something else yet to be named. The challenge is that the test recipe needs to be available the moment about:welcome loads similar to how Optimizely or Mozilla.org' Traffic Cop functions today.

(steps 1-5 above can be done in more parallel given the various teams who need to engage on making it happen. I would prioritize the layout of the page and the iframe over copy tests since we have actual insights that those can are existing pain points for users)

6) We can test the first iteration of about:welcome (experiment variation) with the same final content that exists on /firstrun/ (experiment control) at the end of Q2 or start of Q3. We can also use another control of about:newtab, to see if there is any impact to retention/engagement if we feel this is necessary.

7) After we conclude that there is no regression to engagement or retention on about:welcome vs /firstrun/ with the same content and UX and that it passes all QA/performance/quality checks from Firefox, it could be included by default one of the Firefox trains.

8) After it is live and it is the baseline and that we have insights back from the Critical Event project (finding one or more 'aha! moments' in the early experience of the product), we can run onboarding experiments with where we try more step changes to completely different "first run" experiences and see their impact on retention and qualitative insights.

If we can compress the steps above from a timeline perspective, that would be great so that those step changes (and winning variations) stand to have a positive impact on product key results and KPIs.
Priority: -- → P3
Matt: if we were to move /firstrun/ on www.mozilla.org to an in-product experience at say about:welcome, how would we be able to run a/b tests on the page if it loaded immediately after the product opened? Can we rely on Shield or another in-product testing tool to a/b test that experience? Thanks!
Flags: needinfo?(mgrimes)
Shield is available *very early* but not instantly on startup.
Flags: needinfo?(mgrimes)
If you shipped your variations of about:welcome as a part of the AS system add-on or somewhere else we could use a pref flip to assign users. That is trivial, but also means you can only update your variations every 6 weeks (possibly less) since they have to be bundled with the release.

If we wanted to ship the variations as an add-on study I am confident that for *most* users under *most* circumstances we could deliver a variation in time for onboarding. That does mean that users with slow, spotty, etc connections will not be represented in the population. I've added mythmon as well as he may have some additional thoughts.
Assignee: nobody → ewright
Just a quick note on a requirement for about:welcome to ensure there isn't a regression. In bug 1409661, the bug resolved an issue with /firstrun/ showing up in the Highlights section of Activity Stream. That was resolved and we should ensure about:welcome doesn't show up either. It likely won't since about:welcome is an in-product page, but just wanted to make a note of it here. Thanks!
Is this going to be chrome privileged UI? If so, can we use fluent here?
Comment on attachment 8967857 [details]
Bug 1448918 - Create about:welcome page in preperation for firstrun migration.

https://reviewboard.mozilla.org/r/236514/#review242820

Looks good to me, with one suggestion addressed (or not, as appropriate).  r=dmose

::: browser/components/about/AboutRedirector.cpp:97
(Diff revision 1)
>      nsIAboutModule::ENABLE_INDEXED_DB |
>      nsIAboutModule::URI_MUST_LOAD_IN_CHILD |
>      nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT |
>      nsIAboutModule::ALLOW_SCRIPT },
> +  { "welcome", "about:blank",
> +    nsIAboutModule::ENABLE_INDEXED_DB |

Do we know ahead of time that we're definitely going to need IndexedDB here?  If not, I'd propose leaving out ENABLE_INDEXED_DB until such time as we need it.
Attachment #8967857 - Flags: review?(dmose) → review+
Comment on attachment 8967857 [details]
Bug 1448918 - Create about:welcome page in preperation for firstrun migration.

https://reviewboard.mozilla.org/r/236514/#review242820

> Do we know ahead of time that we're definitely going to need IndexedDB here?  If not, I'd propose leaving out ENABLE_INDEXED_DB until such time as we need it.

This page is going to be running activity stream, so I copied about:newtab. Do we need it to run activity stream?
Comment on attachment 8967857 [details]
Bug 1448918 - Create about:welcome page in preperation for firstrun migration.

https://reviewboard.mozilla.org/r/236514/#review242820

> This page is going to be running activity stream, so I copied about:newtab. Do we need it to run activity stream?

As I understand it, we only need IndexedDB for snippets-related stuff.  k88hudson could confirm that.  So a lot depends on what you mean by "running activity stream"?  I'm guessing you don't mean "displaying about:home/about:newtab".  Can you clarify?
Comment on attachment 8967857 [details]
Bug 1448918 - Create about:welcome page in preperation for firstrun migration.

https://reviewboard.mozilla.org/r/236514/#review242820

> As I understand it, we only need IndexedDB for snippets-related stuff.  k88hudson could confirm that.  So a lot depends on what you mean by "running activity stream"?  I'm guessing you don't mean "displaying about:home/about:newtab".  Can you clarify?

It won't be redirecting to about:newtab nor about:home nor displaying those pages, it'll be rendering activity stream in the same way that each of those pages do, thanks to AboutRedirector.cpp line 161. However, I don't believe it is running snippets, I'll need to look into how snippets are displayed, but I haven't seen any evidence of them.
Comment on attachment 8967857 [details]
Bug 1448918 - Create about:welcome page in preperation for firstrun migration.

https://reviewboard.mozilla.org/r/236514/#review242820

> It won't be redirecting to about:newtab nor about:home nor displaying those pages, it'll be rendering activity stream in the same way that each of those pages do, thanks to AboutRedirector.cpp line 161. However, I don't believe it is running snippets, I'll need to look into how snippets are displayed, but I haven't seen any evidence of them.

k88hudson confirmed, it's only used for snippets, in that case I shouldn't need it.
OK, I know there's some code in TelemetryFeed.jsm that assumes that if you're not on about:home, that means you must be on about:newtab.  I suspect there's code elsewhere that makes similar assumptions.  At some point in this process (not necessarily before landing this patch), it would be good to go through and audit for that sort of thing.  Probably worth a spin-off bug.
Seeing as this portion of the patch is ready and the rest that is under discussion on Github doesn't seem like it will have any changes needed here, I'm going to mark it for check in.
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/047536b1a60a
Create about:welcome page in preperation for firstrun migration. r=dmose
Keywords: checkin-needed
Backed out changeset for browser chrome failures on browser_urlbar_blanking.js

Push with failures: https://is.gd/h6ihBa

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=174594827&repo=autoland&lineNumber=7490

Backout link: https://hg.mozilla.org/integration/autoland/rev/e81cf51a4b2c961441e57e8272f05323b9576710

These are the errors in the log, please take a look also at the assertion:

7490 11:10:51 INFO - GECKO(1071) | Assertion failure: parsedPolicyStr.Find("default-src") >= 0 (about: page must contain a CSP including default-src), at /builds/worker/workspace/build/src/dom/base/nsDocument.cpp:5416
7608 11:12:19 INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/urlbar/browser_urlbar_blanking.js | Test timed out -
7612 11:12:19 INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/urlbar/browser_urlbar_blanking.js | Found a tab after previous test timed out: about:welcome -
8212 11:13:16 INFO - PROCESS-CRASH | Main app process exited normally | application crashed [@ nsDocument::EndLoad()]
10583 11:13:16 ERROR - TEST-UNEXPECTED-FAIL | leakcheck | tab process: missing output line for total leaks!
33868 11:38:20 ERROR - Return code: 1
33870 11:38:20 ERROR - # TBPL FAILURE #
33872 11:38:20 ERROR - The mochitest suite: browser-chrome-chunked ran with return status: FAILURE

Thank you.
Flags: needinfo?(ewright)
thanks, on it!
Flags: needinfo?(ewright)
Attachment #8967857 - Attachment is obsolete: true
A new solution I'm trying is to set the CSP in activity stream, then remove it if the page location is not about:welcome. This allows snippets etc to run as usual when not on about:welcome, and gives about:welcome a csp to pass the tests that were previously failing, without resorting to adding it to the whitelist.

New passing tests with activity stream code in it. https://treeherder.mozilla.org/#/jobs?repo=try&revision=7d078ed210b225b6634e49b5ef468733c79b814f

This means the Activity stream portion of this patch will need to be merged first.
Attachment #8969657 - Attachment is obsolete: true
Attachment #8969657 - Flags: review?(dmose)
This is a clever idea.  In general, I like it.  I need to think about it a bit more, because I'm a bit concerned that there might be races here.  More soon.
Blake: Can you share a demo here or this experience or how others can experience it themselves? Thanks!
Flags: needinfo?(bwinton)
All: what is the rough estimate on when we can expect about:welcome to get on a Firefox train or be available for a Shield experiment? The reason I ask is because we should freeze any copy/image changes to the current web-based /firstrun/ before about:welcome development/QA wrap up, so that we don't have changes happening on /firstrun/ that aren't reflected on about:welcome.
There's a try-build at https://treeherder.mozilla.org/#/jobs?repo=try&revision=cf6d9ff501220bbb30fd9ff721cb29fc652fb691 that people should be able to download and run. (You'll need to go type `about:welcome` in the urlbar to see it, because that part isn't hooked up in that try run.)

And I hear early in 62 is the current estimate for landing, because it's too big to land this late in the cycle.
Flags: needinfo?(bwinton)
Erica, after some discussion, we've decided that we don't want to expand the scope of about:welcome itself with the CSP handling stuff.  So I've bumped the "fix our CSP story and include about:welcome" bug 1448918 to 62.1 so that we can do it at the beginning of the 62 cycle and manage any fallout then.  As far as this patch goes, you could either wait on the CSP handling thing to land, or, I think it would be ok to put back your original "add about:welcome to the whitelist" patch with a comment linking to bug 1448918.  Does that sound reasonable?
Flags: needinfo?(ewright)
Yep, adding it to the whitelist, noting bug 1448918, for now and treating it the same as the other two pages makes sense to me. I'll do that so I don't have to wait for bug 1448918, just in case.
Flags: needinfo?(ewright)
Blocks: 1457565
Comment on attachment 8970310 [details]
Bug 1448918 - Create about:welcome page in preparation for firstrun migration.

https://reviewboard.mozilla.org/r/239112/#review246824

This is looking good; I picked up a few things that I hadn't in my original review, so I've added them here (sorry!).

There will want to be an integration test (eg in browser/extensions/onboarding/test/browser/) once we land code that starts opening about:welcome in production.  Can you make sure this requirement is tracked wherever that is tracked?

::: browser/base/content/tabbrowser.js:4422
(Diff revision 3)
>            // since these pages get their favicon set in browser code to
>            // improve perceived performance.
>            let isNewTab = originalLocation &&
>              (originalLocation.spec == "about:newtab" ||
>                originalLocation.spec == "about:privatebrowsing" ||
> -              originalLocation.spec == "about:home");
> +              originalLocation.spec == "about:home" ||

Presumably, we only want this change if the comment above it is true for about:welcome also.  Is it?  If so, it would be interesting to know where the code that does this is.  Assuming it's true, I'd suggest updating the comment to include about:welcome in the list as well as to mention where in the browser code this stuff gets set.  If it's not true, we probably need code that adjusts that.

::: browser/extensions/onboarding/OnboardingTelemetry.jsm:50
(Diff revision 3)
>      .includes(category);
>  }
>  
>  // Validate the page value is within the list
>  function isValidPage(page) {
> -  return ["about:newtab", "about:home"].includes(page);
> +    return ["about:newtab", "about:home", "about:welcome"].includes(page);

I'm guessing that there need to be some changes to the AS TelemetryFeed.jsm, since it currently assumes that it's always going to be loaded from about:newtab or about:home.  I don't know that that necessarily needs to happen in this bug, but it does need to happen once code lands that starts opening about:welcome in production.  Is the right thing to do here to file a spin-off bug?

::: browser/extensions/onboarding/README.md:19
(Diff revision 3)
>  
>  ## How to show the onboarding notification
>  
>  Besides above settings, notification will wait 5 minutes before showing the first notification on a new profile or the updated user profile (to not put too much information to the user at once).
>  
> -To manually remove the mute duration, set pref `browser.onboarding.notification.mute-duration-on-first-session-ms` to `0` and notification will be shown at the next time you open `about:home` or `about:newtab`.
> +To manually remove the mute duration, set pref `browser.onboarding.notification.mute-duration-on-first-session-ms` to `0` and notification will be shown at the next time you open `about:home`, `about:newtab`, or `about:welcome`.

I believe onboarding.js (the framescript) also needs to be patched in order for the above comment to be true.

::: modules/libpref/init/all.js:2470
(Diff revision 3)
>  pref("security.csp.enable", true);
>  pref("security.csp.experimentalEnabled", false);
>  pref("security.csp.enableStrictDynamic", true);
>  
>  #if defined(DEBUG) && !defined(ANDROID)
> -pref("csp.content_privileged_about_uris_without_csp", "blank,credits,home,logo,newtab,printpreview,srcdoc,studies");
> +// about:welcome has been added until Bug 1448359 is fixed.

Maybe add, "at which time home, newtab, and welcome will all be removed".
Attachment #8970310 - Flags: review?(dmose) → review-
Comment on attachment 8970310 [details]
Bug 1448918 - Create about:welcome page in preparation for firstrun migration.

https://reviewboard.mozilla.org/r/239112/#review246824

One other thing I noticed is that in the browser console, an error is emitted trying to initialize snippets:

<unavailable> activity-stream.bundle.js:3110:9
init
resource://activity-stream/data/content/activity-stream.bundle.js:3110:9
addSnippetsSubscriber/<
resource://activity-stream/data/content/activity-stream.bundle.js:3175:13
dispatch
resource://activity-stream/vendor/redux.js:339:8
messageMiddleware/</<
resource://activity-stream/data/content/activity-stream.bundle.js:1040:5
queueEarlyMessageMiddleware/</<
resource://activity-stream/data/content/activity-stream.bundle.js:1102:5
rehydrationMiddleware/</<
resource://activity-stream/data/content/activity-stream.bundle.js:1046:12
sendNewTabRehydrated
resource://activity-stream/data/content/activity-stream.bundle.js:3386:7
componentWillUpdate
resource://activity-stream/data/content/activity-stream.bundle.js:3373:5
updateClassInstance
resource://activity-stream/vendor/react-dom.js:129:1
beginWork
resource://activity-stream/vendor/react-dom.js:134:60
d
resource://activity-stream/vendor/react-dom.js:158:393
f
resource://activity-stream/vendor/react-dom.js:159:214
g
resource://activity-stream/vendor/react-dom.js:159:462
t
resource://activity-stream/vendor/react-dom.js:167:3
x
resource://activity-stream/vendor/react-dom.js:166:247
r
resource://activity-stream/vendor/react-dom.js:164:368
v
resource://activity-stream/vendor/react-dom.js:163:278
enqueueSetState
resource://activity-stream/vendor/react-dom.js:124:386
p.prototype.setState
resource://activity-stream/vendor/react.js:18:82
p/</a</p.prototype.onStateChange
resource://activity-stream/vendor/react-redux.js:1:4133
dispatch
resource://activity-stream/vendor/redux.js:339:8
messageMiddleware/</<
resource://activity-stream/data/content/activity-stream.bundle.js:1040:5
queueEarlyMessageMiddleware/</<
resource://activity-stream/data/content/activity-stream.bundle.js:1090:5
rehydrationMiddleware/</<
resource://activity-stream/data/content/activity-stream.bundle.js:1059:12
initStore/<
resource://activity-stream/data/content/activity-stream.bundle.js:1124:9
(In reply to Dan Mosedale (:dmose) from comment #42)
> Comment on attachment 8970310 [details]
> Bug 1448918 - Create about:welcome page in preparation for firstrun
> migration.
> 
> https://reviewboard.mozilla.org/r/239112/#review246824
> 
> One other thing I noticed is that in the browser console, an error is
> emitted trying to initialize snippets:
> 

Yeah, the code initializing snippets is in activity stream, so that error will be there until the activity stream portion (whihc turns off snippets for about:welcome) is merged.
See Also: → 1446023
Hello, I'm interested in this work because the FxA tweaks for Fx China repack introduced in bug 1264843 could be affected.

Which will happen first, this or bug 1446023?
Comment on attachment 8970310 [details]
Bug 1448918 - Create about:welcome page in preparation for firstrun migration.

https://reviewboard.mozilla.org/r/239112/#review246824

> Presumably, we only want this change if the comment above it is true for about:welcome also.  Is it?  If so, it would be interesting to know where the code that does this is.  Assuming it's true, I'd suggest updating the comment to include about:welcome in the list as well as to mention where in the browser code this stuff gets set.  If it's not true, we probably need code that adjusts that.

It's true that it makes a difference. If it is not on this list the icon will briefly disappear. You can see this by refreshing an about:newtab page, and refreshing an about:welcome page (without it on the list), there should be no change at all to the tab. The favicons seem to be set in various places - for a new tab it is set on line 2398 in `tabbrowser.js`, for a new window, it is set in `browser.js` line 1274. For navigating a tab, I haven't been able to find the code that sets it - though there is a favicon href in the xhtml of the pages.

You can also see the same flicker on refresh if it is not part of the list in `isBlankPageURL` in `UtilityOverlay.js` (which I've added in the next iteration of this patch)

> I'm guessing that there need to be some changes to the AS TelemetryFeed.jsm, since it currently assumes that it's always going to be loaded from about:newtab or about:home.  I don't know that that necessarily needs to happen in this bug, but it does need to happen once code lands that starts opening about:welcome in production.  Is the right thing to do here to file a spin-off bug?

Yeah, some changes to AS telemetry have already been made.
See Also: 1446023 → 
Comment on attachment 8970310 [details]
Bug 1448918 - Create about:welcome page in preparation for firstrun migration.

https://reviewboard.mozilla.org/r/239112/#review248362

Looks good; thanks for the updates!  r=dmose
Attachment #8970310 - Flags: review?(dmose) → review+
Keywords: checkin-needed
As a note, bug 1446023 blocks the portion of this bug on Github waiting to be merged with activity stream, but not the part that is waiting on review board.
We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again.

hg error in cmd: hg rebase -s b22e558af67ec6a9815d6f43a108a8681f458d56 -d b869cf66d81a: rebasing 463060:b22e558af67e "Bug 1448918 - Create about:welcome page in preparation for firstrun migration. r=dmose" (tip)
merging browser/base/content/browser.js
merging browser/base/content/tabbrowser.js
merging browser/components/about/AboutRedirector.cpp
merging browser/components/build/nsModule.cpp
merging modules/libpref/init/all.js
warning: conflicts while merging browser/components/about/AboutRedirector.cpp! (edit, then use 'hg resolve --mark')
warning: conflicts while merging browser/components/build/nsModule.cpp! (edit, then use 'hg resolve --mark')
warning: conflicts while merging modules/libpref/init/all.js! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
Keywords: checkin-needed
Pushed by csabou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4c8fdb3ae218
Create about:welcome page in preparation for firstrun migration. r=dmose
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/4c8fdb3ae218
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox62: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 62
Commits pushed to master at https://github.com/mozilla/activity-stream

https://github.com/mozilla/activity-stream/commit/c132f298c64b3e357d8a492e77299fcf2c3c25fa
Bug 1448918 - Migrate Firefox Desktop's first run experience from a web page to an in-product experience.

https://github.com/mozilla/activity-stream/commit/20df47894f281cab281474221d643d2d9d6d4f62
Merge pull request #4090 from ericawright/basic

Bug 1448918 - Migrate Firefox Desktop's first run experience from a w…
Blocks: 1464246
tracking-firefox62: --- → +
Keywords: feature
To any of the CC or people following this bug. If you want to test about welcome yourself, just download Firefox 62 (on nightly now) and go to about:welcome in the awesomebar. It should load the in-product first run. If you create a completely new profile, it will load the web based www.mozilla.org first run because the configuration has not yet changed as we need to test /firstrun/ vs about:welcome vs nothing as seen in bug 1464246.

Thanks to everyone who helped us get to this point!
Hi Erica,

QA would need details on what kind of QA involvement is expected for this. We need to understand how to test this and if this will be treated as a Bug work or we need to follow the full process (Test Plan, Sign Off etc.).

Could you please refer this (https://mana.mozilla.org/wiki/display/PI/PI+Request) and submit a PI request? We would need this submitted by June 4th, your earliest response would be appreciated!

Thank you!
Flags: needinfo?(ewright)
I just had a quick test of about:welcome, nice work!

There is a new "Firefox Account Features" page [1] that
you might want to consider using for the 
"Learn more about Firefox Accounts" link. The intent
of this new page is essentially to replace the Sync features
page [2]. I am unsure whether [1] has been fully released
to the public, :shobson worked on it and would know more.

Stephanie, has the Firefox Accounts Features page been
released to the public or are there still loose ends to
tie off?

[1] - https://www.mozilla.org/en-US/firefox/accounts/features/
[2] - https://www.mozilla.org/en-US/firefox/features/sync/
Flags: needinfo?(shobson)
(In reply to Shane Tomlinson [:stomlinson] from comment #56)
> [1] - https://www.mozilla.org/en-US/firefox/accounts/features/

This is not localized, it's en-US only, while https://www.mozilla.org/firefox/features/sync/ 

I would avoid using it, given the page would be exposed to all languages.
(In reply to Tania Maity from comment #55)
> Hi Erica,
> 
> QA would need details on what kind of QA involvement is expected for this.
> We need to understand how to test this and if this will be treated as a Bug
> work or we need to follow the full process (Test Plan, Sign Off etc.).
> 
> Could you please refer this
> (https://mana.mozilla.org/wiki/display/PI/PI+Request) and submit a PI
> request? We would need this submitted by June 4th, your earliest response
> would be appreciated!
> 
> Thank you!

Also adding the Trello link here:
https://trello.com/c/mpPTLbfx/542-migrate-firefox-desktops-first-run-experience-from-a-web-page-to-an-in-product-experience#

Just for your reference, we track the Milestones/Test Results in Trello.
(In reply to Tania Maity from comment #58)
> (In reply to Tania Maity from comment #55)
> > Hi Erica,
> > 
> > QA would need details on what kind of QA involvement is expected for this.
> > We need to understand how to test this and if this will be treated as a Bug
> > work or we need to follow the full process (Test Plan, Sign Off etc.).
> > 
> > Could you please refer this
> > (https://mana.mozilla.org/wiki/display/PI/PI+Request) and submit a PI
> > request? We would need this submitted by June 4th, your earliest response
> > would be appreciated!
> > 
> > Thank you!
> 
> Also adding the Trello link here:
> https://trello.com/c/mpPTLbfx/542-migrate-firefox-desktops-first-run-
> experience-from-a-web-page-to-an-in-product-experience#
> 
> Just for your reference, we track the Milestones/Test Results in Trello.

Hi Tania, thanks for all the references, I'll be in contact shortly
Flags: needinfo?(ewright)
There is progress on removing the iframe on /firstrun/ and we should make the same change to about:welcome. The removing the iframe bug is in bug 1446023. Will we be able to implement the same non-frame code on about:welcome so that when it launched in September that we don't go regress back to an iframe?
(In reply to Chris More [:cmore] from comment #60)
> There is progress on removing the iframe on /firstrun/ and we should make
> the same change to about:welcome. The removing the iframe bug is in bug
> 1446023. Will we be able to implement the same non-frame code on
> about:welcome so that when it launched in September that we don't go regress
> back to an iframe?

Yes, the code that is currently in about:welcome does not use an iframe.
(In reply to Erica Wright [:ewright] from comment #61)
> (In reply to Chris More [:cmore] from comment #60)
> > There is progress on removing the iframe on /firstrun/ and we should make
> > the same change to about:welcome. The removing the iframe bug is in bug
> > 1446023. Will we be able to implement the same non-frame code on
> > about:welcome so that when it launched in September that we don't go regress
> > back to an iframe?
> 
> Yes, the code that is currently in about:welcome does not use an iframe.

Even better! Thanks.
While it may not be a regular use case, it is worth noting that about:welcome doesn't seem to be detecting the user state in regards to FxA so a signed-in user will still see the login form if they navigate directly to about:welcome

The current experiences displayed FxA preferences (in the iFrame). Given we've gotten rid of the iFrame, I'm not sure what we would want to put there.
:ewright: What do you think about a probe or some event saying about:welcome has been loaded (like would exist if it was on a website)?
Flags: needinfo?(ewright)
(In reply to Chris More [:cmore] from comment #64)
> :ewright: What do you think about a probe or some event saying about:welcome
> has been loaded (like would exist if it was on a website)?

I just double-checked the AS telemetry, and events are already built in - but will now be sending "about:welcome" as the page name. So we have events for interactions with AS content, as well as an "impression" event sent on arriving on the page. I added a few events for clicks that are unique to this new page.

Unless you are asking for load time, which we do not have, and would be obscured since Activity Stream will be loading at the same time.
Flags: needinfo?(ewright)
(In reply to Erica Wright [:ewright] from comment #65)
> (In reply to Chris More [:cmore] from comment #64)
> > :ewright: What do you think about a probe or some event saying about:welcome
> > has been loaded (like would exist if it was on a website)?
> 
> I just double-checked the AS telemetry, and events are already built in -
> but will now be sending "about:welcome" as the page name. So we have events
> for interactions with AS content, as well as an "impression" event sent on
> arriving on the page. I added a few events for clicks that are unique to
> this new page.

Ok, this should be good. Just wanted to make sure there was at least some impression data on about:welcome loading, which should be immediately after the new profile ping, but nice to have a second metric. Thanks!

> 
> Unless you are asking for load time, which we do not have, and would be
> obscured since Activity Stream will be loading at the same time.
The Firefox Accounts Features page is still in a testing phase and so is currently English only.

We just got the results of some qualitative testing and will likely open the page up to localization after we have integrated that feedback.

I don't know the timeline for that to happen, sorry.
Flags: needinfo?(shobson)
Depends on: 1470336
Depends on: 1472209
See Also: → 1473041
Depends on: 1478610
Depends on: 1483214
Finished testing all locales troughtout the beta cycle, no related issues found.
Testing was done under Windows 10x64, macOS 10.12.6 and Ubuntu 16.04.
Only two issues ( bug 1483214, bug 1478610) were discovered during this testing phase but we don't consider them to be blockers so the feature is looking good.
Depends on: 1490826
Depends on: 1506625
See Also: → simple-aw
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: